home *** CD-ROM | disk | FTP | other *** search
/ Whiteline: delta / whiteline CD Series - delta.iso / document / hypertxt / ximgtool / ximgtool.eng < prev    next >
Text File  |  1995-11-25  |  10KB  |  229 lines
  1.     Documentation for XIMGTOOL and IMGCODEC-sourcecode
  2.  
  3.             Version: Apr 25 1995
  4.  
  5.  
  6. 1. Overview
  7. """""""""""
  8.  
  9. Hereby an extension of the IMG format for monochrome and color
  10. palette images is given. The purpose was to generalize the known
  11. IMG codec method as far as possible and thereby to increase the
  12. achievable compression ratio, without introducing completely new
  13. algorithms.
  14.  
  15. The result is the definition of 3 stages of the IMG format, called
  16. Level 1, 2, and 3. Level 1 is thereby the 'compatibility'-Level,
  17. that is identical with the old method. Level 2 and 3 define certain
  18. extensions in a way, that an appropriate decoder is able to handle
  19. the lower Levels without additional effort. Such a decoder is pro-
  20. vided in sourcecode and is designed for flexible usage in applica-
  21. tion programs. The utility XIMGTOOL demonstrates the usage of the
  22. decoder as well as the given encoders and should serve as a tool
  23. for arbitrary conversion between Levels. Furthermore, at the same
  24. time with the hereby published tool and the sources a new 1STGUIDE-
  25. version is released which already includes the Level-3-Decoder, so
  26. it can be used for the practical proof of the methods.
  27.  
  28. The effect of the achieved improvements in compression ratio by the
  29. extensions varies and depends on the type of the images. Especially
  30. at typical screen snapshots of desktop scenes or line- or object-
  31. drawings significant savings of 15 % average, in some cases around
  32. 30 %, were achieved. Fewer savings occur in photo-style images, but
  33. also here a couple of KBytes can be saved at typical material.
  34.  
  35.  
  36. 2. Level-Definition
  37. """""""""""""""""""
  38.  
  39. The Level of an IMG file is marked by writing the according number
  40. into the 'IMG-version' entry of the IMG header. This is the first
  41. word in the file and therefore is easy to recognize in a hex dump.
  42. Until now there was found the value 1. This is now interpreted as
  43. Level-1. At a Level-2 coded image here is now written the value 2,
  44. at Level-3 the value 3. This is mainly thought for information
  45. purposes only, because the recommended and provided Level-3-Decoder
  46. works independently from this value!
  47. Some programs check for the version number and warn the user, if
  48. this value is greater than 1. This is correct, because the programs
  49. probably won't work well yet with the here defined extensions.
  50. Other programs (so also older versions of 1STGUIDE) produce 'screen
  51. garbage', if you try to load Level-2 or Level-3 images with them.
  52. A program, which checked for maximum version number 1 so far, can
  53. make a test for maximum 3 after built in the Level-3-Decoder, to
  54. remain reliability.
  55.  
  56. Now a short description of the features of the different Levels
  57. is given (see in the sourcecodes for details):
  58.  
  59.  
  60. Level-1:
  61. --------
  62. Compatibility, so should be processable by all programs, which
  63. already handled IMG files correctly so far.
  64. - Compression methods are restricted to planes, that is neither
  65.   plane- nor line-overflow is allowed within a packing mode.
  66. - vertical replication count (vrc): 1 to 255 times repeat the
  67.   current line.
  68. - pattern run: 1 to 255 times repeat a pattern.
  69. - solid run: 1 to 127 times repeat a 0/0xFF-byte.
  70. - byte string: Copy the next 1 to 255 bytes.
  71.  
  72. Level-2:
  73. --------
  74. - Packing modes need not longer be restricted to the planes of a
  75.   line. But the line-limit is going on to be a restriction.
  76. - At vertical replication count (vrc) and byte string a zero byte
  77.   count value is interpreted as a count of 256.
  78. - Introduction of 'extended vertical run mode': Coding of a repea-
  79.   ted byte sequence in respect to the line before by specially in-
  80.   terpreted stuffing byte 0xFF of 'full' vrc. This can be considered
  81.   as generalization of the 'full vrc' to repeated partial sequences
  82.   of a line.
  83.  
  84. Level-3:
  85. --------
  86. - Here we get away with any restriction of packing modes to
  87.   line-limits too! Thanks to the used ('object oriented') data
  88.   structures, only a single line buffer is still required for
  89.   decoding.
  90. - All mentioned Level-2 extensions are valid here too, of course.
  91.  
  92.  
  93. The effect of the extensions on the compression ratio does, as
  94. mentioned, vary. Especially the 'extended vertical run mode' in-
  95. troduced with Level-2 provides significant savings on some images,
  96. while being meaningless on others.
  97. The removed plane-limit-coding at Level-2 has, of course, the grea-
  98. ter effect, the more planes (colors) are given. In monochrome images
  99. this has no effect, here the achieved savings are mainly due to the
  100. extended vrc.
  101. The removed line-limit-coding at Level-3 allows little savings
  102. over Level-2 - nearly 1 byte per line average, sometimes less,
  103. sometimes more. Try this out and make your own experiences!
  104.  
  105.  
  106. 3. XIMGTOOL.TTP
  107. """""""""""""""
  108.  
  109. With this utility you have the possibility to extensively test and
  110. use the capabilities of the various image coding methods.
  111.  
  112. Usage:  ximgtool [options] input [output]
  113.  
  114. options:
  115.  
  116.  
  117. -lN:
  118. ----
  119. Use Level-N-Encoder, N=1..3. Default is input value cropped to 1..3.
  120. So if you want to compress given IMG files (Level-1) with a maximum
  121. degree, write -l3. The so produced files may, of course, only be
  122. decompressed and viewed by capable (Level-3) decoders, at the moment
  123. this is the current 1STGUIDE-version. Other programs will hopefully
  124. follow soon. But you can use this nevertheless for instance for
  125. archiving of images: With XIMGTOOL you can convert back the files to
  126. the compatible Level-1 for reuse with other programs if necessary.
  127. To do this write -l1. XIMGTOOL itself always uses the universal
  128. Level-3-Decoder.
  129. The used and provided encoders are already the result of an inten-
  130. sive optimization process. So even the compatible Level-1-Encoder
  131. usually produces smaller files than the most effective programs so
  132. far that I know. Only in very rare cases a little loss occured. So
  133. the optimum isn't reached yet with the given encoders and further
  134. enhancements are possible in the future, while the decoder should
  135. not allow significant changes.
  136.  
  137. -pN:
  138. ----
  139. Force output pattern run N, N=1..2. Default is input value cropped
  140. to 1..2.
  141. The pattern run is a global IMG variable and therefore does not
  142. allow to be optimized in a single pass. Some images achieve higher
  143. comression ratios at 1, other at 2. You have to try this out if you
  144. want the optimum, but mostly the difference is not that great (a few
  145. bytes), so it isn't worth to worry too much.
  146.  
  147. -i:
  148. ---
  149. Identify input, no coding.
  150.  
  151. -m:
  152. ---
  153. Multiple mode (batch). Allows use of a standard wildcard pattern as
  154. input to process multiple files in a directory. ATTENTION for
  155. GEMINI-users: In the console window you have to 'quote' the wildcard
  156. pattern to prevent the shell from automatic argument expansion!
  157. As output a destination folder may be given.
  158.  
  159.  
  160. input:  source file (pattern if -m).
  161.  
  162. output: destination file (folder if -m).
  163.  
  164. After processing some statistics are shown: the number of input
  165. bytes, output bytes, and the difference between them (saved bytes).
  166. The latter is usually positive (saving) if converting to a higher
  167. Level, and negative (wasting) if converting to a lower Level.
  168. Note: Also without giving an 'output' a full coding is done (then
  169. only in memory), and the according results are displayed. This can
  170. be useful for testing purposes.
  171. An extended XIMG-header is completely ignored by XIMGTOOL, it is
  172. directly copied into the output file.
  173.  
  174.  
  175. 4. IMGCODEC-Sourcen
  176. """""""""""""""""""
  177.  
  178. In order to force an easy and widespread usage, complete sources for
  179. coding and decoding are provided. Look at the included comments for
  180. details.
  181. While, as mentioned above, the given decoder does not allow signi-
  182. ficant changes, the encoders do probably allow to be optimized yet,
  183. although some effort has already been spent on them. The encoders
  184. are designed to take advantage of all available coding schemes, and
  185. an own vrc-handling is done independently from the input coding.
  186. So for the same image contents there should be always the same
  187. result, not depending on the input coding.
  188. If you find enhancements of the encoders, you are welcome to make it
  189. available. But be aware: It is easy to construct an encoder that
  190. wins on special contents, but looses more on others. It always
  191. depends on the test material, this should be as great and applica-
  192. cation-typical as possible. Only if you find a routine which pro-
  193. vides significant savings on typical images and which only looses
  194. little in exceptional cases, it can be generally considered.
  195.  
  196. Aside from the raw codec-sources you will find application examples
  197. for MFDB-input and -output, which can serve as sample for appro-
  198. priate applications.
  199.  
  200.  
  201. 5. Preview
  202. """"""""""
  203.  
  204. Presently the extension of the IMG format for True-Color-support
  205. (generally Direct-Color, since High-Color-modes will be included,
  206. too) is prepared. Because secondary processing of this type is
  207. somewhat more sophisticated, the given Level-Specification should
  208. be published first to satisfy some interested people who asked for
  209. this. The TC-extension will be independent from the given Level-
  210. Spec, and the current routines will work with this extension with-
  211. out changes, since this extension deals only with specifying an
  212. extended IMG-header for appropriate interpretation of pixel data.
  213. The pixel data itself is handled by the same scheme.
  214. The XIMGTOOL.TTP will also be useful for the TC-files, since it
  215. works independently from the extended header information and in-
  216. terpretation of pixel data.
  217.  
  218.  
  219. 6. Reference
  220. """"""""""""
  221.  
  222. If you have comments or suggestions, please write to the following
  223. address:
  224.  
  225.     Guido Vollbeding
  226.     Turmstraβe 61
  227.     D-06110 Halle (Saale)
  228.     Germany
  229.